As computing needs for organizations have increased, and as organizations plan for growth, one common way to plan for, and obtain economical computing is to purchase computing systems that are scalable. A system or architecture is scalable when it can be upgraded or increased in size or reconfigured to accommodate changing conditions. For example, a company that plans to set up a client/server network may want to have a system that not only works with the number of people who will immediately use the system, but also can be easily and economically expanded to accommodate the number of employees who may be using the system in one year, five years, or ten years. In another example, a company that runs a server farm and hosts web pages or applications via the Internet may continue to grow, and this company would desire a scalable system where they can economically add servers as needed to accommodate growth.
Accordingly, scalable server systems can merge or integrate a number of scalable servers or chasses having one or more processors to create a “larger” unitary system having processing nodes. Thus, a collection of scalable servers can function like a single larger server when properly merged. When multiple servers are merged they can be partitioned using hardware partitioning. A system with a single partition can run a single instance of an operating system (OS) and all the nodes of the system are thus conceptually combined. Thus, in effect, the user will experience a single, more powerful computing system, functioning as one “scaled up” node, instead of a number of less powerful nodes running independently.
A traditional approach for combining multiple nodes of a system into a single-partition merged system running a single instance of an OS is to have a trained technician manually integrate and configure each node as a system is built or as computing resources (nodes) are added. Traditionally, a trained technician or administrator must configure each node with the proper partition configuration information, entering data to specify or configure one of the nodes as the primary, or boot node, and the other nodes as secondary nodes to the primary node. This approach is cumbersome, and requires trained technicians to build and configure such a system. When there are more than a few nodes to manually configure, the configuring process can get complex and such configuring is prone to connection and configuration errors and omissions.
As stated above, one issue in scalable processing systems is that after the processing components are cabled together, each component must be configured such that all components can boot together and operate together in the desired configuration. Also, as stated above, in most systems the customer/user must manually designate one node as a primary node or a boot facilitator. This process may require that the primary node is capable of communicating with the other nodes, for example, the primary node as well as the secondary nodes must be “turned on” or “up and running.” The “technician” configuring the system, has to know information about the connected nodes, addresses etc. and the technician typically has to manually enter that data into a user interface to describe which nodes should boot together etc. A typical customer setup is where all the components that are cabled together are desired to boot as a single entity, as a single partitioned system or as a system that runs a single operating system. Traditionally, many scalable server systems utilize a management interface (a standalone computing system with specialized hardware) to properly boot the connected server nodes. It can be appreciated that this approach requires costly dedicated hardware, and may require modification to preexisting systems that do not allow for the addition of such functionality.
In many scaled server systems, nodes can communicate with intelligent platform management interface (IPMI) commands. This protocol can be utilized to monitor server hardware components for temperature, voltage, chassis intrusion, etc. and can provide limited control for various system operations. The IPMI concept was introduced in 1998 by many major server producers. Generally, IPMI commands are a standard set of messages for the characteristics of hardware components such that servers can communicate and function together. Sensors in the system can provide data to a baseboard management controller (BMC), (a controller on a circuit board) which can send IPMI messages over the server's system bus to the network as well as over an independent, internal Platform Management Bus (IPMB).
Alternately described, an intelligent platform management interface (IPMI) can be understood as a hardware level interface specification that defines a common, abstracted, message-based interface to platform monitoring and control functions. As a hardware-level interface, the IPMI can reside at the bottom (the lowest level) of a typical management software stack.
“Power up” issues can also be a concern for scalable systems. One approach to address this issue is to have a “luck-of-the-draw” or timing-based approach programmed into the nodes of the system. When a node boots up, the node can determine whether a single-partition merged system is already running, and if so, the node can join the partition or system. If the node does not find a preexisting system or partition to join, it can start one, and become the primary node and create a “new system.” The new node thus can become a primary node due to timing issues and the luck of the draw. Such an approach, however, can be complex, and often does not provide the administrator with control over which node becomes the primary node.
Generally, systems in a scalable environment do not automatically know that they are cabled together and can work as one system. These scalable systems have to be told (i.e. configured by a technician) such that they know that they are cabled to other nodes and must be configured regarding how they can communicate with other nodes. There are many current designs available that utilize this manual configuration approach. One design uses a network such as an Ethernet connection between nodes and utilizes dedicated hardware such as a remote supervisor adapter (RSA) to facilitate set up of the system.
The RSAs can communicate with each other on Ethernet (embedded service on each RSA) and can instruct the scalable components to work together with a set partitioning. This system, among other things, requires a user to input the Internet Protocol (IP) addresses of each RSA, in the RSA interface before the scalable systems can work as a single entity. This process can be cumbersome for a user to discover and enter the RSA IP address for each component. This IP detection process can include booting each scalable component and after the component is connected to the network the user can request and find the IP address in the BIOS menu of the component. Another traditional arrangement uses a service location protocol (SLP) discovery routine to detect all scalable components via the system's RSA Ethernet network connections. Then the arrangement can iterate through the list of SLP scalable systems and an application can send a message (ping) through each scalable system port and detect received messages on another scalable system port. Each scalable system relies on RSA Ethernet protocol to initiate and detect how other scalable systems interconnect. In the end, all scalable connections are determined for all SLP scalable systems.
This Ethernet based arrangement does not exchange comprehensive system information and such information can depend on the intercommunication of scalable components via RSA Ethernet. One solution utilizes SLP to discover the communication mechanism, which can find a large number of systems. Only the number of RSAs connected to that network limits the number of discovered systems. Often not all of these detected systems can be operated as a single identity. This can cause extra time filtering through the systems not capable of scalability.
Another approach is to connect the servers and configure virtual building blocks. These building blocks can be broken down to any level, but this is generally only supported in a Linux environment. These systems often utilize a relatively complex set-up procedure. Such a set up can also require extensive hardware and software overhead. Many traditional systems can require an Ethernet communication system to communicate set up commands to all of the subsystems. Further, it is expensive to require a trained technician be present at every installation or every system expansion.